home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98b.txt / 000087_icon-group-sender _Mon Jun 15 16:24:49 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id QAA18510
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Mon, 15 Jun 1998 16:24:49 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA19502; Mon, 15 Jun 1998 16:24:40 -0700
  7. From: gep2@computek.net
  8. Date: Mon, 15 Jun 1998 14:52:04 -0500
  9. Message-Id: <199806151952.OAA02701@axp.cmpu.net>
  10. Mime-Version: 1.0
  11. Content-Type: text/plain
  12. Content-Transfer-Encoding: 7bit
  13. Subject: Re: Directory access facilities
  14. To: icon-group@optima.CS.Arizona.EDU
  15. X-Mailer: SPRY Mail Version: 04.00.06.17
  16. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  17. Status: RO
  18. Content-Length: 1993
  19.  
  20. >> Anyone else have ideas (or votes) on how to do directory access
  21. > facilities?
  22.  
  23. > My admittedly biased and possibly Unix-centric view: we don't need any
  24. elaborate solutions, I think the idea of each read() returning one entry
  25. from the directory is the best one. This finesses all the issues of quoting
  26. blanks, quotes, wildchars etc. etc. 
  27.  
  28. "Finesses" -> "Ignores".
  29.  
  30. > If you need more information about the
  31. entry, you use the function that performs this query. In Unicon, you use
  32. stat(), which returns a record. Here's the "ls" example:
  33.  
  34. >   f := open(".") | stop( ... )
  35.    while write( format( stat( read(f) ) ) )
  36.  
  37. The problem (if you want something RELIABLE) with this kind of thing is that on 
  38. multitasking systems (especially those crossing boundaries through a network) 
  39. the entries can be changing (and entries even being added and deleted) WHILE you 
  40. are retrieving your way through them.  It's much more robust to return a 
  41. snapshot, which at least _was_ valid and consistent at the time the snapshot was 
  42. taken.
  43.  
  44. It's entirely possible that (for example) the read(f) returns a temporary file 
  45. name, which is no longer there by the time the stat() is issued for it.  If 
  46. stat() failed (e.g.) in such a case, then you'd terminate your while loop 
  47. prematurely.
  48.  
  49. Agreed that it's almost as flakey to try to load a snapshot into a table in 
  50. memory... where that table could be of nearly arbitrary size... due to both the 
  51. memory space available to hold it, and the (atomic) time it takes to generate 
  52. such a potentially huge table.
  53.  
  54. > ...We should stick to a clean and simple interface that will work 
  55. unambiguously without all sorts of special cases. 
  56.  
  57. Like the old saying, it should be "as simple as possible... BUT NO SIMPLER."
  58.  
  59. > Others have already pointed out why a space-separated string of all the 
  60. entries is a bad idea.
  61.  
  62. Agreed, that's not a good solution.
  63.  
  64. Gordon Peterson
  65. http://www.computek.net/public/gep2/
  66. Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
  67.  
  68.